跳到主要内容

改进的开发工作流

· 阅读需 8 分钟
Random Image
图片与正文无关

为什么从 Git flow 改为 Gitlab flow?​

Git flow 虽然很经典，但是毕竟协作分支太多，要求整个团队对 Git 要有更深的理解，否则容易出现混乱，这里不去具体说明两个分支的优缺点和异同，经过一段时间的试验，我觉得 Gitlab flow 比之前的流程简单，也没有引起任何异常，算是平稳过渡，使用了 Gitlab flow 之后，每个人的效率都有一定程度的提高。

用 Push flow 还是 Fork flow​

选择了 Gitlab flow 之后，还要选择使用 push flow 或者 fork flow，这两种工作流都很好理解，我们是这样考虑的，对于熟悉流程的团队成员，我们采用 push flow，对于新进团队成员，在考察期内，我们采用 fork flow，这样在 merge request 时，纠正一些因为不熟悉流程，规范，代码而引起的错误。一旦新进成员完全熟悉并理解了流程，规范，代码，就可以切到 push flow。

为什么要用持续集成？​

首先，Gitlab flow 抛弃了 develop 分支，因此各个 feature 分支就必须有自己的环境进行测试，所以说多环境是 Gitlab flow 的前置条件，但是环境多了，部署如果还是人工部署，那仍然是很繁琐的，所以说 Gitlab flow 提出了多环境的要求，持续集成完美的解决了这个问题。

我们的持续集成是借助于 Gitlab 内置的持续集成机制，当然其实也可以用其他的 CI/CD 工具，重点是自动化。多环境强调的是自动部署，如果为了保证质量，还需要前置一些环节进行自动化测试。

我们在自动化测试上面的经验不多，所以目前的自动化测试基本上是个摆设，主要享受的是自动部署带来的遍历。

多环境带来的混乱​

我们这边单方面引入多环境之后，关联项目调用我们的接口时，配置我们的服务器就成了问题，都是开发环境，以前只有一个 dev，现在还有了 release-2-10，release-3-0，此时就需要相关项目的测试环境配合修改配置，使相关服务可以指向我们的开发分支的环境，这样时间长了，其他项目组的小伙伴肯定也会不胜其烦，所以还有优化的空间。

今天在旭东的提醒下，提出是否可以设置一个不变的中间域名，我们内部切分支，开始的时候想这样不是要手动维护这几个中间环境嘛？其实不必，最终找到解决办法，在 Nginx 配置里进行环境的重定向，可以在保留自动部署的前提下，也让相关服务不用频繁切换地址，只要我们这边通过配置切即可，相关配置如下：

Nginx 片段

if ($slug = for-crm) {
  set $slug release-3-0;
}
if ($slug = for-practice) {
  set $slug release-3-0;
}

这样依赖我们就有了一些分支环境之外的虚拟环境，这些虚拟环境会按需指向到我们不同的分支，并且这些分支都是自动部署的。

充分利用 Gitlab 和 JIRA 功能​

我们在长期维护一个项目的时候最常问的两个问题：

  • 一个是这个任务你是怎么解决的？这就要求我们有一个视图，能够看到一个任务关联的 commits。

  • 另一个是这个 commit 的代码为什么这么写？这也要求我们的代码的每一次 commit 的 log 都要关联一个任务。

同时考虑以上两种场景，我们需要在提交代码的 log 格式上做约定，同时还要利用 JIRA 和 Gitlab 整合的机制，将提交和任务进行系统工具层面的整合。

充分利用 JIRA 的功能还体现在充分使用其基于敏捷开发思想实现的项目管理工作流，每个人都要深度参与使用 JIRA 进行每次迭代。

测试人员在开发环境就参与测试​

为了减轻正式提测时的负担，我们在多环境的帮助下，让测试人员进入开发分支环境参与测试，并不断反馈已经完成模块的 BUG。这里的思考是，在开发分支环境测试的越充分，提测到 dev 环境以及仿真环境测试就会越顺利，就越有可能按时上线。这也算是一种持续交付，只不过是交付给测试人员做质量保证工作。开发过程中的 BUG 修复应该说是成本最低的，包括开发人员和测试人员的沟通成本也是最低的。

不过在实际操作过程中，测试人员反馈测试比较混乱，对于提交的 BUG，开发人员可能已经修复了，但是却没有及时告知，导致测试无法知道何时进行复测。经过讨论，觉得改变任务的接收人，任务状态，或者任务标签，任务阶段这样的协作状态本身都会带来一定的混乱（比如忘记操作），所以，我们直接约定即时通知即可。但是通知的方式必须是 Worktile 的私人消息，消息中包含任务引用和必要的说明。由于 Worktile 本来就是用来协作的，所以比微信或者邮件要更直接有效。

守门员机制​

对于线上系统，既要维护线上需求，又要进行大的版本迭代，而大版本迭代往往有 deadline，为了保证迭代的按时上线，就要保证项目组员尽可能专注于迭代开发，少被打断。但合理的维护需求也应该提供响应，所以引入守门员机制，迭代进行过程中，所有的维护需求都交给守门员处理。守门员只有在自己解决不了的情况下才向其他组员求助，从而为其他组员的迭代开发赢得时间。守门员的数量根据项目组规模来定。